服務圖Service graphs

服務圖是顯示各種服務間互相關聯的視覺呈現。它能幫助用戶：

• 推斷分散式系統的拓撲。隨著分散式系統的擴大，它們變得越來越複雜，服務圖幫助您了解系統的結構。
• 提供系統健康狀態的高級概覽，顯示錯誤率、延遲等相關數據。
• 提供系統拓撲的歷史視圖，查看這些系統隨著時間如何發展。
  

工作原理:

metrics-generator 處理追蹤數據並以 Prometheus 指標的形式生成服務圖。

服務圖通過檢查追蹤數據來工作，尋找具有代表請求的父子關係的跨度。處理器使用 OpenTelemetry 的語義規範來檢測各種請求。它目前支持以下請求：

• 兩個服務之間的直接請求，其中發出和接收的跨度必須分別具有 span.kind、client 和 server。
• 跨消息系統的請求，其中發出和接收的跨度必須分別具有 span.kind、producer 和 consumer。
• 數據庫請求；在此情況下，處理器查找包含屬性 span.kind=client 以及 db.name 的跨度。

每個可以配對成請求的跨度都保留在內存存儲中，直到收到其相應的配對跨度或超過最大等待時間。當達到這些條件之一時，將記錄該請求並從本地存儲中刪除。

每個發出的指標序列都有與執行請求的服務和接收請求的服務相對應的 client 和 server 標籤。

tempo_service_graph_request_total{client="app", server="db", connection_type="database"} 20

虛擬節點

虛擬節點是跟踪的生命週期的一部分，但由於它們超出了用戶的範疇（例如，用於支付處理的外部服務）或未經儀器化（例如，前端應用程序），因此不收集它們的跨度。

可以用兩種不同的方式檢測到虛擬節點：

• 根跨度的 span.kind 設置為 server。這表示請求是由未經儀器化的外部系統啟動的，例如前端應用程序或通過 curl 的工程師。
• client跨度沒有其匹配的server跨度，但存在同儕屬性。在這種情況下，我們假設對外部服務進行了調用，對於此 Tempo 不會接收跨度。
  • 默認的同儕屬性是 peer.service、db.name 和 db.system。
  • 屬性的順序很重要，因為第一個出現的將被用作虛擬節點的名稱。

指標

以下指標已被導出：

指標

以下指標已被導出：
指標名稱 類型 標籤 描述
traces_service_graph_request_total 計數器 client, server, connection_type 兩節點間的請求總數
traces_service_graph_request_failed_total 計數器 client, server, connection_type 兩節點間失敗的請求總數
traces_service_graph_request_server_seconds 直方圖 client, server, connection_type 伺服器端看到的兩節點間的請求時間
traces_service_graph_request_client_seconds 直方圖 client, server, connection_type 客戶端看到的兩節點間的請求時間
traces_service_graph_unpaired_spans_total 計數器 client, server, connection_type 未配對跨度的總數
traces_service_graph_dropped_spans_total 計數器 client, server, connection_type 被丟棄的跨度總數

持續時間同時從客戶端和伺服器端進行測量。

connection_type 的可能值：unset、messaging_system 或 database。

可以使用尺寸配置dimensions包括額外的標籤。

由於服務圖處理器必須處理一條邊的兩側，因此它需要正確地處理跟踪的所有跨度。如果跟踪的跨度分散在多個實例上，則不會可靠地配對跨度。

從跟踪估計基數

當您有很多服務時，基數可能會構成問題。這個問題沒有直接的公式或解決方案。以下指南應該有助於估計該功能將產生的基數。

要瞭解更多有關基數的資訊，請參考基數文檔。

如何估計基數

邊的數量取決於系統中的節點數量以及它們之間的請求方向。我們稱這個數量為跳數（hops）。每次跳躍都將是 client + server 標籤的獨特組合。

例如：

• 一個有 3 個節點（A、B、C）的系統，其中 A 只呼叫 B，B 只呼叫 C，將有 2 個跳數（A → B，B → C）。
• 一個有 3 個節點（A、B、C）的系統，它們互相呼叫（即，都是雙向連接）將有 6 個跳數（A → B，B → A，B → C，C → B，A → C，C → A）。
  我們不能基於節點自動計算跳數，但它應該是 #services - 1 和 #services 之間的值！

如果我們知道一個系統中的跳數，我們可以計算生成的服務圖的基數：

  traces_service_graph_request_total: #hops
  traces_service_graph_request_failed_total: #hops
  traces_service_graph_request_server_seconds: 3 buckets * #hops
  traces_service_graph_request_client_seconds: 3 buckets * #hops
  traces_service_graph_unpaired_spans_total: #services (absolute worst case)
  traces_service_graph_dropped_spans_total: #services (absolute worst case)

最後，我們得到以下的基數估計：

 Sum: 8 * #hops + 2 * #services

注意：要估計指標的數量，請參考 Dry run metrics generator 文檔。

如何運行

服務圖在 Tempo 中生成並推送到指標存儲。然後，它們可以在 Grafana 中表示為圖形。您需要這些組件來完全使用服務圖。

** 注意：** 當您有大量服務時，基數可能會構成問題。要了解有關基數的更多信息，以及如何執行指標生成器的幹運行，請參閱基數文檔。

在 Tempo/GET 中啟用服務圖

要在 Tempo/GET 中啟用服務圖，請啟用指標生成器並添加一個覆蓋部分，啟用service-graphs。有關配置詳細信息，請參閱此處。

在 Grafana 中啟用服務圖

注意：自 Grafana 9.0.4 起，服務圖已默認啟用。在 Grafana 9.0.4 之前，服務圖在feature toggle tempoServiceGraph 下是隱藏的。

通過將其連接到正在發送指標的 Prometheus 後端，配置 Tempo 數據源的 “服務圖”：

apiVersion: 1
datasources:
  # Prometheus backend where metrics are sent
  - name: Prometheus
    type: prometheus
    uid: prometheus
    url: <prometheus-url>
    jsonData:
        httpMethod: GET
    version: 1
  - name: Tempo
    type: tempo
    uid: tempo
    url: <tempo-url>
    jsonData:
      httpMethod: GET
      serviceMap:
        datasourceUid: 'prometheus'
    version: 1

總結

服務圖是通過跟踪生成的視覺化表示，可以幫助理解系統結構、健康狀況以及系統的拓撲變化。